…atrixorigin#24919)

Root cause: newShuffleJoinScopeList leaves a CNs dop join buckets in
separate RemoteRun trees while the shuffle dispatch attaches to only the
first one. In compileMultiUpdate (used by large INSERT...SELECT),
newMergeScope sends each bucket individually -> checkPipeline detects
dispatch.LocalRegs pointing to out-of-tree sibling buckets -> converts to
local on coordinator -> dispatch runs on wrong CN, mispaired with
compile-time cross-CN receiver FromAddr -> remote GetProcByUuid spins /
merge WaitingEnd waits forever -> 5M+ rows hang.

Fix: add groupShuffleBucketsByCNIfNeeded (gating: multi-CN + cross-CN
dispatch present) which merges same-CN shuffle buckets and their nested
dispatch into one per-CN send unit via mergeScopesByCN. When the whole
group is sent as one RemoteRun unit to its target CN, the dispatch runs
on the correct CN, checkPipeline returns true, and the cross-CN receiver
handshake completes normally. Noop for single-CN / non-shuffle inserts.

Wired into compileInsert and compileMultiUpdate (toWriteS3 + !toWriteS3,
4 call sites). Verified on 2-CN docker cluster: 5Mx2 consecutive runs
complete in ~17s with count(*)=5,000,000 and correct data; previously
hung forever.

Co-Authored-By: Claude <noreply@anthropic.com>

- document scopeTreeHasCrossCNDispatch precondition (dispatch is always RootOp)
- document that grouping preserves callers existing root operator via AppendChild
- extend grouping to the compileInsert S3 sink-scan path: dataScope.MergeRun
  still sends each bucket individually, so a cross-CN shuffle dispatch there
  would hit the same convert-to-local hang; group same-CN buckets first

Co-Authored-By: Claude <noreply@anthropic.com>

…24919 review)

XuPeng-SH review: in the compileInsert non-S3 path each bucket carries an
Insert as its top-level RootOp. groupShuffleBucketsByCNIfNeeded would move
those Insert ops into a per-CN Merge container PreScopes, where
run()/affectedRows() (which only walk the RootOp child chain, not PreScopes)
miss them -> data written but "0 rows affected".

The other grouped paths are unaffected: their write op already sits in
PreScopes with a top-level aggregator (mergeblock for write-S3 insert,
FlushS3Info for multi-update) that reports affected rows, so grouping only
deepens PreScopes without changing the accounting. Non-S3 inserts are small
and do not produce cross-CN shuffle, so removing grouping here loses no hang
coverage.

Co-Authored-By: Claude <noreply@anthropic.com>

…24919 review)

Critical: my earlier "skip grouping in non-S3 insert" was wrong. toWriteS3 is
decided by INSERT output size (~35K-row threshold) while cross-CN shuffle is
decided by JOIN input size + CN count -- independent. A large shuffle join with
a highly selective filter / low match rate yields few output rows (non-S3) yet
still shuffles across CNs, so the non-S3 path can carry a cross-CN dispatch and
would silently hang without grouping.

Apply groupShuffleBucketsByCNIfNeeded BEFORE attaching Insert, so the per-CN
container gets Insert as its RootOp (Insert -> Merge): checkPipeline returns
true (no hang) and affectedRows() still finds the Insert on the RootOp chain
(correct row count). Noop when no cross-CN dispatch is present.

Also from review:
- scopeTreeHasCrossCNDispatch: document the intentional narrower scope vs
  checkPipelineStandaloneExecutableAtRemote (dispatch only, not connector).
- isSameCN: log malformed-address fallback at Warn (was Debug) so a wrong-CN
  merge is visible in ops.

Co-Authored-By: Claude <noreply@anthropic.com>